@@            Coverage Diff             @@
##             main   #62066      +/-   ##
==========================================
- Coverage   89.68%   89.66%   -0.02%     
==========================================
  Files         676      688      +12     
  Lines      206575   212553    +5978     
  Branches    39549    40713    +1164     
==========================================
+ Hits       185262   190592    +5330     
- Misses      13446    14080     +634     
- Partials     7867     7881      +14     

... and 44 files with indirect coverage changes

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Methodology

Six benchmarks comparing classic Node.js streams (stream.Readable/stream.Writable/pipeline) against the new stream/iter API across representative usage patterns. All benchmarks run with --expose-gc for forced GC before/after measurement, and use PerformanceObserver to capture GC event counts, types, and pause durations.

Each benchmark runs warmup iterations first, then measured iterations with memory snapshots (via process.memoryUsage() and v8.getHeapStatistics()) taken before and after the measured window.

Benchmark Results

1. Simple Pipe-Through

Scenario: 64MB of 64KB chunks piped from source to no-op sink. 10 iterations.
Measures baseline piping overhead without transforms.

Analysis: Iter uses less heap per run due to the absence of ReadableState, WritableState, _events, and EventEmitter infrastructure. The higher minor GC count for iter-async reflects more frequent short-lived promise allocations from the async generator protocol, but each is cheap and efficiently collected by Scavenge. Iter-sync eliminates nearly all allocation since generators produce no promises.

2. SSR-Type Concurrent Streams

Scenario: 100 concurrent streams, each producing 100KB through a buffer-copy transform with 4KB chunks. 5 iterations. Simulates server-side rendering workloads.

Analysis: The most dramatic result. Classic streams allocate approximately 25 objects per stream (Readable + Writable + ReadableState + WritableState + _events x 2 + pipeline scaffolding + end-of-stream listeners + closures). With 100 concurrent streams x 5 iterations = 500 stream lifecycles, that is roughly 12,500 objects from infrastructure alone. Iter avoids all of this as generators and plain objects have near-zero construction overhead. The 73% RSS reduction is significant for server workloads.

3. Backpressure

Scenario: 8MB of 16KB chunks with a slow consumer that delays every 8th write by 1ms. 5 iterations. Tests buffer memory growth under sustained pressure.

Analysis: Under backpressure, classic streams buffer {chunk, encoding, callback} objects per write in the Writable's internal buffer -- 133KB of heap growth. Iter-push uses a RingBuffer with just the chunk reference -- 7.7KB, 95% less buffer overhead. The pull model avoids buffering entirely because the source only yields when the consumer requests data.

The iter-pull result (2.3ms) reflects the writeSync try-fallback pattern: 7 out of 8 writes complete synchronously, entirely avoiding the setTimeout delay. This is a valid demonstration of the pull model's advantage -- the sync fast path avoids async overhead when the writer can handle data synchronously.

4. Many Short-Lived Streams

Scenario: 10,000 streams, each producing 4KB (4 x 1KB chunks). 3 iterations. Measures per-stream construction/teardown overhead and GC pressure from rapid allocation and deallocation.

Analysis: The most revealing benchmark for construction/teardown overhead. Classic streams at 10,000 stream lifecycles triggers 23 GC events totaling 87.73ms -- 18.7% of total runtime is GC. Each classic stream creates approximately 25 objects (Readable, Writable, two States, _events, pipeline closures, end-of-stream listeners). Over 10K x 3 iterations x 25 = roughly 750,000 objects created and immediately abandoned. Iter creates a generator + plain object per stream, perhaps 3-4 objects. GC pause drops from 87.73ms to 8.04ms.

5. Deep Transform Chain

Scenario: 16MB of 16KB chunks through 5 identity transforms to a no-op sink. 5 iterations. Measures per-transform memory overhead.

Analysis: Each classic Transform is a full Duplex stream (Readable + Writable + both States + _events + pipeline wiring) -- 5 transforms means roughly 125 infrastructure objects. Iter fuses all 5 stateless transforms into a single generator layer -- one additional generator frame regardless of depth. The sync path achieves zero net heap growth.

6. Fan-Out

Scenario: 1 source producing 16MB of 16KB chunks consumed by 4 readers. 5 iterations. Classic uses pipe() to PassThrough streams; iter uses broadcast.

Analysis: Fan-out is the one scenario where classic streams are faster. pipe() to multiple PassThrough streams is highly optimized in Node.js. However, broadcast uses dramatically less memory: 14.7KB vs 132.8KB heap delta. Classic creates 4 PassThrough streams (each a full Duplex) + pipe wiring + end-of-stream listeners. Broadcast shares a single RingBuffer with cursor-based consumers where each consumer is just a {cursor, resolve, reject, detached} state object.

Structural Comparison

Per-Stream Construction Cost

Per-Chunk/Per-Batch Hot Path Cost

GC Impact Model

The fundamental difference: classic streams create many long-lived objects that survive young generation collection (State objects, _events, listener closures live for the stream's entire lifetime). This promotes them to old space, requiring expensive Mark-Sweep collection.

Stream/iter creates mostly short-lived objects (iterator results, promises) that die within one async tick and are efficiently collected by Scavenge (minor GC).

For high-churn scenarios (many short-lived streams), classic streams create and abandon ~25 objects per stream lifecycle that must all be traced and collected. Iter creates ~3-5 objects. The GC impact scales linearly with stream count -- at 10K streams, classic spends 88ms in GC vs iter's 8ms.

Summary

Stream/iter is consistently more memory-efficient across all scenarios, with the advantage most pronounced in high-concurrency and high-churn workloads. The only throughput concession is fan-out, where classic's highly-optimized pipe() path is slightly faster -- but even there, broadcast uses dramatically less memory.

The pull model's inherent backpressure (source only yields on demand) eliminates buffer-related memory growth entirely for the most common use pattern. The batch-oriented design (Uint8Array[] rather than individual chunks) amortizes the per-item overhead of Promises and iterator results across all chunks in a batch, making the async iteration protocol overhead negligible at typical chunk sizes.

Methodology

Six benchmarks comparing the Web Streams API (ReadableStream/WritableStream/TransformStream/pipeTo/pipeThrough/tee) against the new stream/iter API across representative usage patterns. All benchmarks run with --expose-gc for forced GC before/after measurement, and use PerformanceObserver to capture GC event counts, types, and pause durations.

Each benchmark runs warmup iterations first, then measured iterations with memory snapshots (via process.memoryUsage() and v8.getHeapStatistics()) taken before and after the measured window.

Benchmark Results

1. Simple Pipe-Through

Scenario: 64MB of 64KB chunks piped from source to no-op sink. 10 iterations.

Analysis: Web Streams trigger 30 minor GCs for the same data volume -- one roughly every 21MB of throughput. Each pipeTo iteration creates internal reader/writer pairs, promise-per-chunk from the pull protocol, and controller state. Iter-async needs only 6 minor GCs (one promise per batch from the async generator). Iter-sync eliminates minor GC entirely. The 90% heap reduction reflects iter's absence of ReadableStreamDefaultController, WritableStreamDefaultController, ReadableStreamDefaultReader, internal queuing strategy objects, and the per-chunk promise overhead of the Web Streams pull protocol.

2. SSR-Type Concurrent Streams

Scenario: 100 concurrent streams, each producing 100KB through a buffer-copy transform with 4KB chunks. 5 iterations.

Analysis: The most dramatic result. At 100 concurrent streams, Web Streams consume 30MB of RSS growth while iter shows none. Each Web Streams pipeline creates ReadableStream + TransformStream + WritableStream, each with their own controllers, internal queues, [[readableStreamController]] / [[writableStreamDefaultWriter]] internal slots, strategy objects, and promise machinery. That is approximately 30-40 objects per stream. 100 streams x 5 iterations = 500 lifecycles producing roughly 15,000-20,000 infrastructure objects. Iter produces a generator + plain objects per stream -- approximately 3-5 objects.

3. Backpressure

Scenario: 8MB of 16KB chunks with a slow consumer that delays every 8th write by 1ms. 5 iterations.

Analysis: Under backpressure with equivalent delay patterns, Web Streams and iter-push perform similarly on time (both dominated by the 1ms delays). However, Web Streams show 6.19MB RSS growth vs zero for iter-push. Web Streams' internal queuing strategy allocates queue entries with { value, size } wrappers and maintains separate [[queue]] arrays on both the readable and writable sides. Iter-push uses a single RingBuffer with direct chunk references.

The pull model (2.7ms) demonstrates its structural advantage: the writeSync try-fallback pattern means 7/8 writes complete synchronously, entirely skipping the delay. The Web Streams pull protocol has no sync fast path -- every controller.enqueue() / reader.read() goes through the promise-based pull protocol.

4. Many Short-Lived Streams

Scenario: 10,000 streams, each producing 4KB (4 x 1KB chunks). 3 iterations.

Analysis: The GC pressure difference is staggering. Web Streams trigger 267 minor GCs for 30,000 stream lifecycles (10K x 3 iterations) -- nearly one Scavenge per 112 streams. Each ReadableStream + WritableStream pair creates controllers, internal slot objects, queuing strategy instances, and the pipeTo algorithm creates ReadableStreamDefaultReader + WritableStreamDefaultWriter with their own promise slots. At approximately 30+ objects per stream pair, that is 900,000+ objects created and abandoned.

Iter-async triggers only 36 minor GCs (87% fewer) because each stream lifecycle creates roughly 3-5 objects (generator, iterator object, argument parsing result). The GC pause time difference (20.65ms vs 11.05ms) means Web Streams spend 6.3% of total runtime in GC vs iter's 11.2%. While iter's GC percentage is higher, its total runtime is 3.3x shorter, so the absolute time in GC is still lower.

5. Deep Transform Chain

Scenario: 16MB of 16KB chunks through 5 identity transforms to a no-op sink. 5 iterations.

Analysis: The widest performance gap. Each Web Streams TransformStream creates a ReadableStream + WritableStream pair internally (with all their controllers and internal slots), plus the transform controller. 5 transforms = 5 full stream pairs = approximately 150+ infrastructure objects, and every chunk passes through 5 promise-based pull cycles. The pipeThrough chain creates 5 pipeTo algorithms running concurrently, each with its own reader/writer pair.

Iter fuses all 5 stateless transforms into a single generator layer. One additional generator frame regardless of transform depth. The per-chunk cost is 5 function calls (the transforms) with no additional promise or object creation. 59 minor GCs for Web Streams vs 8 for iter reflects the massive object creation difference.

Iter-sync achieves 2.9ms with zero minor GC -- the entire pipeline runs as synchronous function calls through a single generator.

6. Fan-Out

Scenario: 1 source producing 16MB of 16KB chunks consumed by 4 readers. 5 iterations.

Analysis: Web Streams' tee() creates a full branch of the stream for each split. To get 4 consumers from tee(), two levels of teeing are needed (rs.tee() then tee each branch), creating 6 ReadableStream instances total with their controllers, internal queues, and per-chunk promise resolution. Each tee branch independently copies chunk references and maintains separate queue state.

Broadcast shares a single RingBuffer across all consumers. Each consumer is a {cursor, resolve, reject, detached} state object -- 4 objects vs Web Streams' 6 full stream instances with controllers. The 97% heap reduction reflects this fundamental architectural difference: shared buffer with cursors vs independent queue copies.

Structural Comparison

Per-Stream Construction Cost

Per-Chunk Protocol Cost

GC Pressure Model

Web Streams create many medium-lived objects per pipeline: controllers, readers, writers, strategy objects, and internal queue entries. These objects live for the duration of the stream but are recreated for each new stream instance. The per-chunk promise overhead (2+ promises per chunk from the read/write protocol) generates significant young-generation pressure.

Stream/iter creates few short-lived objects per batch: one iterator result and one promise from the async generator yield. The writeSync fast path eliminates write-side promise creation entirely. Batch amortization means the per-chunk overhead is divided by batch size.

The GC data across all 6 benchmarks:

Summary

Stream/iter outperforms Web Streams on every metric across every scenario tested. The advantages are structural:

1. No controller/reader/writer object overhead. Web Streams require ReadableStreamDefaultController, ReadableStreamDefaultReader, WritableStreamDefaultController, WritableStreamDefaultWriter, and queuing strategy instances per stream. Iter uses generators and plain objects.

2. No per-chunk promise tax. Web Streams' pull protocol requires at minimum 2 promises per chunk (reader.read() + writer.write()). Iter's batch model amortizes one promise per batch across all chunks, and the writeSync fast path eliminates the write-side promise entirely.

3. Transform fusion. Web Streams' pipeThrough creates a full ReadableStream + WritableStream pair per transform. Iter fuses consecutive stateless transforms into a single generator layer regardless of depth.

4. Shared-buffer fan-out. Web Streams' tee() creates independent stream branches with separate queues. Broadcast shares a single RingBuffer with cursor-based consumers.

The result is an average 82% reduction in GC events, with the gap widest in transform-heavy and high-churn workloads where Web Streams' object-per-stream and promise-per-chunk costs compound.